In
`@api-test/src/main/java/io/mosip/testrig/apirig/masterdata/testrunner/MosipTestRunner.java`:
- Around line 104-106: The loop in MosipTestRunner.java that clears and sets
BaseTestCase.languageList uses a hardcoded `i < 1` which will attempt
`localLanguageList.get(0)` even when the source list is empty; modify the loop
to guard against empty lists (e.g., iterate up to Math.min(1,
localLanguageList.size()) or add an explicit check `if
(localLanguageList.isEmpty()) return/continue` before the loop) so that the code
in the block that calls BaseTestCase.languageList.clear() and
BaseTestCase.languageList.add(localLanguageList.get(i)) never executes when
localLanguageList is empty.

In `@api-test/src/main/resources/config/masterdata.properties`:
- Around line 21-42: This file contains hardcoded secrets (keys like
keycloak_Password, postgres-password, audit_password, partner_password, and
mosip_*_client_secret / AuthClientSecret) which must be removed from source;
replace each literal value with a reference to a runtime secret (e.g.,
environment variable names or a single external secrets file path) and update
consumers to read from env or a secret loader instead of masterdata.properties,
add the external secrets file pattern to .gitignore (or ensure env-only usage),
and after changing the file rotate the exposed credentials and purge them from
git history (BFG/git-filter-branch) to eliminate the committed secrets.

In
`@api-test/src/main/resources/masterdata/DeleteUserCenterMapping/DeleteUserCenterMapping.yml`:
- Line 5: The description field in DeleteUserCenterMapping.yml is truncated
("vali"); update the description value for the test case in
DeleteUserCenterMapping to the full sentence, e.g., "Verify that the system
successfully deletes a user-center mapping when all details are valid", by
editing the description entry in the DeleteUserCenterMapping.yml file (look for
the description key in the DeleteUserCenterMapping test definition).

In `@api-test/src/main/resources/config/masterdata.properties`:
- Around line 254-260: The properties OTPTimeOut, attempt, ConfigParameters, and
langselect in masterdata.properties appear unused; either remove them to reduce
config clutter or add documentation comments above each explaining intended
purpose, valid values, and where they are consumed (e.g., OTPTimeOut -> OTP
expiry in seconds, attempt -> retry count, ConfigParameters -> comma-separated
keys, langselect -> environment language selector). Update the file by deleting
unused lines or replacing them with commented descriptions and example values,
and if you keep them, add a short comment referencing the related feature or
future ticket/constant name so their purpose is clear (refer to property names
OTPTimeOut, attempt, ConfigParameters, langselect).

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@api-test/src/main/resources/masterdata/DeviceType/CreateDeviceType.yml`:
- Line 67: The test description is inaccurate: it asserts a duplicate-code error
(KER-MSD-053) because the payload reuses "code": "AUTO3$TESTDATACONTEXT$" (same
as TC_01), not a duplicate name; update the description in CreateDeviceType.yml
to say it verifies that creating a device type with a duplicate code is rejected
(mention KER-MSD-053) and ensure any textual references to "name" in this test
are replaced with "code" so the intent matches the asserted error.

In
`@api-test/src/main/resources/masterdata/FetchAllDocumentCategories/FetchAllDocumentCategories.yml`:
- Line 5: The test description in FetchAllDocumentCategories.yml incorrectly
mentions "language code and code filters" even though the request to
/documentcategories/all has no input; update the YAML 'description' value to a
concise, accurate sentence such as "Verify that the system can fetch all
document categories successfully" (or similar) so it reflects the actual test
behavior.

In `@api-test/src/main/resources/masterdata/FetchDevice/FetchDevice.yml`:
- Line 86: There is a wording typo in the YAML description: replace the
nonstandard word "unexisting" with "non-existent" in the description string used
by FetchDevice (the description field in FetchDevice.yml) so it reads "Verify
that the system returns an error when a non-existent device type is used to
fetch device records".

In `@api-test/src/main/resources/masterdata/FetchDeviceSpec/FetchDeviceSpec.yml`:
- Line 56: Update the description string in the FetchDeviceSpec test YAML where
it currently reads "unexisting device type code" to use the correct term
"non-existent device type code"; locate the description field under the
FetchDeviceSpec.yml test case (the line that starts with description: Verify
that the system returns an error when an unexisting device type code is used to
fetch device specification records) and replace "unexisting" with
"non-existent".

In `@api-test/src/main/resources/masterdata/FetchHolidays/FetchHoliday.yml`:
- Line 55: The description strings containing the phrase "unexisting" (e.g.,
"Verify that the system returns an error when an unexisting holiday ID is used
to fetch holiday records") should be updated to use standard English—replace
"unexisting" with "non-existing" or "nonexistent" consistently across all
occurrences (including the other similar descriptions noted in the file). Locate
the exact description lines in FetchHoliday.yml and perform a find-and-replace
of "unexisting" → "nonexistent" (or "non-existing") so all three instances are
corrected.

In `@api-test/src/main/resources/masterdata/FetchIdSchema/FetchIdSchema.yml`:
- Around line 3-5: The test description incorrectly says it "fetches all ID
schema records" while the endPoint is /v1/masterdata/idschema/latest; update the
description in FetchIdSchema.yml (uniqueIdentifier
TC_Masterdata_FetchIdSchema_01, endPoint /v1/masterdata/idschema/latest) to
state that it verifies fetching the latest ID schema (for a given/valid language
code) — wording must clearly differ from the FetchAllIdschema test to avoid
confusion.

In `@api-test/src/main/resources/masterdata/FetchLocation/FetchLocation.yml`:
- Line 111: Update the duplicate test descriptions so TC_06 and TC_09 are
clearly distinct: change TC_06's description to reference both parameters and
its endpoint (e.g., "Verify that the system successfully fetches location
details for a given locationcode and langcode via
/locations/info/{locationcode}/{langcode}") and change TC_09's description to
reference its endpoint and scope (e.g., "Verify that the system successfully
fetches location level data for a given langcode via
/locations/level/{langcode}"); edit the description fields for the tests
identified as TC_06 and TC_09 to use these clearer, endpoint-specific phrasings.
- Line 228: Update the test description for TC_12 in FetchLocation.yml so it
accurately reflects the expected output: change the sentence that says the
system "returns an error" to state that the system returns a validation status
"Invalid" (e.g., "Verify that the system returns a validation status of
'Invalid' when an invalid location name is used to fetch location details");
locate the TC_12 test block in FetchLocation.yml to make this exact wording
change.

In
`@api-test/src/main/resources/masterdata/FetchMissingDynamicField/FetchMissingDynamicField.yml`:
- Line 5: Update the YAML test descriptions so TC_01 and TC_02 are distinct:
change TC_01's description (currently phrased as "Verify that the system
successfully fetches all missing dynamic field records with valid input data")
to explicitly state it tests fetching missing dynamic fields when fieldName is
null (no specific field filter), and change TC_02's description to explicitly
state it tests fetching missing dynamic fields for a specific fieldName
("description"); locate the two descriptions by the test IDs TC_01 and TC_02 in
FetchMissingDynamicField.yml and replace the generic text with these clarified,
scenario-specific descriptions.

In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml`:
- Around line 838-841: The test case
MasterData_FetchRegCent_By_Pagination_HierarchyLevel_Text_langCode_MorePageSize_Neg
has a misleading description: the endpoint query uses pageNumber=100&pageSize=5
so the failure is due to an out-of-range page number, not an oversized page
size; update the description field for this YAML entry to state that it verifies
an error is returned when the page number is out of range (e.g., "Verify that
the system returns an error when an out-of-range page number is used to fetch
paginated registration center records by hierarchy level and language code") so
it accurately matches the endPoint and intent.

In
`@api-test/src/main/resources/masterdata/FetchRegCentDeviceHistory/FetchRegCentDeviceHistory.yml`:
- Line 71: The test case description string in the FetchRegCentDeviceHistory
YAML has inconsistent capitalization—change the description value from "verify
that the system returns an error when invalid effective date-time values are
provided while fetching the registration center device history" to start with a
capital "V" ("Verify ...") so it matches the other test descriptions; update the
description field in the FetchRegCentDeviceHistory.yml test case accordingly.

In `@api-test/src/main/resources/masterdata/FilterHolidays/FilterHolidays.yml`:
- Line 27: TC_02 and TC_09 in FilterHolidays.yml share identical descriptions
but test different filter columns and expectations; update each test description
to mention the specific column and expected result (e.g., TC_02: "Verify
filtering by isActive returns totalCount: 0 when invalid filter text is
provided" and TC_09: "Verify filtering by holidayName returns an empty response
when invalid filter text is provided") so test reports are unambiguous and
easier to triage.

In
`@api-test/src/main/resources/masterdata/GetApplicantType/GetApplicantType.yml`:
- Line 682: The description for TC_22
(Masterdata_GetApplicantType_DOB_lessThanAYear) is misleading — it says the
system should return an error or handle gracefully, but the test expects a
successful response (uses outputTemplate
masterdata/GetApplicantType/getApplicantTypeResult and asserts applicantTypeCode
"005"). Update the description to reflect the expected success outcome, e.g.,
"Verify that the system returns the correct applicant type when the date of
birth is less than a year old," so it matches the test case name and expected
output.

In
`@api-test/src/main/resources/masterdata/GetHolidaysMissingIds/GetHolidaysMissingIds.yml`:
- Around line 18-21: Fix the typo in the test case key by renaming
Admin_GetHolidaysMissingIds_InValid_Inavild_langCode to a correct, clear key
(e.g., Admin_GetHolidaysMissingIds_InValid_Invalid_langCode or
Admin_GetHolidaysMissingIds_Invalid_langCode) in GetHolidaysMissingIds.yml;
update any external references (test runners, reports, skip lists, or other YAML
entries) that use the old key so they point to the new key to avoid breaking
test resolution.

In
`@api-test/src/main/resources/masterdata/GetMissingDocumentTypeByLangcode/GetMissingDocumentTypeByLangcode.yml`:
- Line 5: Update the YAML test descriptions to reflect that this endpoint
returns missing document type IDs rather than all document types: change both
description fields in GetMissingDocumentTypeByLangcode (and the duplicated case
at 20-20) to mention "missing document types" or "missing document type IDs" and
include the endpoint path /documenttypes/missingids/{langcode} or the test name
GetMissingDocumentTypeByLangcode to clarify the intent.

In
`@api-test/src/main/resources/masterdata/GetTemplateFileFormat/GetTemplateFileFormat.yml`:
- Around line 42-45: The test case
Masterdata_GetTemplateFileFormat_langcode_allValid_smoke has an inaccurate
description and a duplicate uniqueIdentifier; update its description to state
that it verifies retrieval of a template file format without a language code
(since the endpoint is /v1/masterdata/templatefileformats/code/{code} and
"langcode" is set to "$REMOVE$") and change the uniqueIdentifier from
TC_Masterdata_GetTemplateFileFormat_02 to TC_Masterdata_GetTemplateFileFormat_03
so it no longer collides with the inValid_code test case.

In `@api-test/src/main/resources/masterdata/GetTemplateType/TemplateType.yml`:
- Line 42: The two test case descriptions in TemplateType.yml are duplicated;
update the description for TC_03 to explicitly state it validates behavior when
both {code} and {langcode} are provided (e.g., "Verify system response when
fetching template types with both {code} and invalid {langcode}") and update
TC_05 to explicitly state it validates behavior when only {langcode} is provided
(e.g., "Verify system response when fetching template types with only an invalid
{langcode}"), locating the descriptions by the test IDs TC_03 and TC_05 in the
file.

---

Outside diff comments:
In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml`:
- Around line 871-884: The test case
MasterData_FetchRegCent_By_Pagination_HierarchyLevel_Text_Without_langCode_Neg
(uniqueIdentifier TC_Masterdata_FetchRegCent_30) has a mismatch: the
description/name claim the language code is missing but the input contains an
invalid langcode ("hhgghaJ"); update either the input or the metadata so they
match—either remove/omit the "langcode" field (or set it to the $REMOVE$ token)
in the input template to truly test a missing langcode, or change the test
name/description to indicate "invalid langcode" and keep the current input;
ensure you edit the description and the test identifier text
(MasterData_FetchRegCent_By_Pagination_HierarchyLevel_Text_Without_langCode_Neg
and description string) or the input's "langcode" field accordingly.

In `@api-test/src/main/resources/masterdata/GenderFilter/GenderFilter.yml`:
- Around line 79-104: The test case
Masterdata_GenderFilter_ValidTextAsEmpty_Smoke has an incorrect description: the
input shows "type": "" (empty) while "text" is "Genderdummy" and the expected
error is about the filter type; update the description to say the filter type is
empty (e.g., "Verify system behavior when the filter type is empty") and, if
templateFields should reflect the dynamic fields used in the input, add "type"
to templateFields (replace or augment ["text"] with ["type","text"]) so the
metadata matches the payload.
- Around line 203-223: The test case
Masterdata_GenderFilter_InValidTextAsNonExisting has a misleading description;
change the description field to state that the system returns an empty result
set (no matches) when a non-existing filter text is provided rather than saying
it "returns an error", and keep the existing outputTemplate (genderFilterResult)
and expected output {"filters": []} unchanged so the description matches the
test assertions.

---

Nitpick comments:
In `@api-test/src/main/resources/masterdata/FetchRegCent/FetchRegCent.yml`:
- Line 532: Update the positive-path test descriptions to include the word
"successfully": edit the description fields in FetchRegCent.yml for the relevant
test cases (e.g., the description for TC_19 and TC_13) so they read
"...successfully fetches registration center records..." (or similar) instead of
the current phrasing; locate the description entries by the test case IDs TC_19
and TC_13 and adjust the description strings accordingly.
- Line 357: Update the description field in this test case to match other
positive-path wording by inserting "successfully" so it reads: "Verify that the
system successfully fetches registration center records by hierarchy level and
list of text using a valid language code." Edit the description entry in
FetchRegCent.yml (the test case's description property) to apply this exact
phrasing for consistency with TC_01/TC_02/TC_05.

In
`@api-test/src/main/resources/masterdata/GetApplicantType/GetApplicantType.yml`:
- Line 434: The description string "Verify that the system returns applicant
type entries correctly when FLE, NFR, and CHL flags are set to true." has a
trailing period that is inconsistent with other descriptions; remove the final
period so the description ends without punctuation. Locate the YAML entry with
the description field in GetApplicantType.yml (the line containing that exact
description text) and update it to match the punctuation style used elsewhere.

In
`@api-test/src/main/resources/masterdata/GetUserDetailsByIdAndEffDate/GetUserDetailsByIdAndEffDate.yml`:
- Line 38: Rename the mistaken test key
MasterData_GetUserDetailsByIsAndEffDate_InValid_effDate to
MasterData_GetUserDetailsByIdAndEffDate_InValid_effDate; locate the entry named
MasterData_GetUserDetailsByIsAndEffDate_InValid_effDate in
GetUserDetailsByIdAndEffDate.yml and update the string `Is` → `Id` so the key
reads MasterData_GetUserDetailsByIdAndEffDate_InValid_effDate consistently.